chore(deps): update all non-major dependencies - #86

v0.1.92

Compare Source

• Resolve double_must_use clippy lint in generated code (#​303)

v0.1.91

Compare Source

• Update to syn 3 (#​299)
• Fix mutability for by-reference receivers (#​301)

v0.1.90

Compare Source

(yanked)

v17.6.0

Compare Source

Minor Changes

• #​1850 938d3f4 - Task functions like { title, task } can now use a logger function log() to emit output while the task runs. By default, the output will only be visible if the task fails, unless the --verbose option was used. Additionally, when the task rejects, the error will be shown in the output.

  import { defineConfig } from 'lint-staged/config'
  
  export default defineConfig({
    '*': {
      title: 'Fail if PDF files are committed',
      task: async (filepaths, { log }) => {
        const pdfFiles = filepaths.filter((f) => f.toLowerCase().endsWith('.pdf'))
        if (pdfFiles.length > 0) {
          log('PDF files should not be committed: %s', pdfFiles)
          throw new Error('Failed')
        }
      },
    },
  })

• #​1854 30562bc - lint-staged now stages changes to all tracked files modified by tasks, including files that weren’t originally staged or didn’t match the configured globs. This can happen when your task has side-effects, or it's a function that ignores the staged files like () => "prettier --write .".

  If you have unstaged changes in a file and the task also edits that file, your unstaged changes will be staged too. Use --hide-unstaged to hide your changes while tasks run.

Patch Changes

• #​1860 4296532 - The assignment of staged files to lint-staged configuration files (when using multiple, for example in a monorepo) has been rewritten to be more efficient. As a reminder, each staged file is assigned to exactly one configuration (the closest one), even if that config doesn't match the file in its globs.

• #​1861 c45f28a - Fix running parallel tasks for a single glob, when tasks are created by a function. Nesting one level of arrays inside an array of tasks will result in the inner tasks running in parallel. This behavior should now be consistent when creating tasks using functions. In the following example eslint and prettier will run in parallel (for all files, when any JS files are staged):

  import { defineConfig } from 'lint-staged/config'
  
  export default defineConfig({
    '*.js': () => [['eslint --max-warnings=0 .', 'prettier --list-different .']],
  })

• #​1859 f0ea69d - Various performance improvements from skipping redundant internal Git calls.

• #​1856 69d7d17 - Partially staged changes are hidden in a uniquely-named patch file to avoid multiple invocations of lint-staged overwriting it. This makes it safer to run lint-staged in multiple worktrees at the same time.

v17.5.1

Compare Source

Patch Changes

• #​1852 bfcca94 - Fix TypeScript issue TS1254 from defineConfig() by changing the signature from const to a function:

  A 'const' initializer in an ambient context must be a string or numeric literal or literal enum reference.

v17.5.0

Compare Source

Minor Changes

• #​1847 f9063b7 - Lint-staged now refuses to run when files were staged with --intent-to-add, because Git stash doesn't support them. Previously this was an unhandled error.

Patch Changes

• #​1848 d718ccc - Lint-staged now handles color support better in non-TTY streams, and honors the FORCE_COLOR environment variable.

• #​1845 7e5ece8 - Update tinyexec@1.3.1 so that local binaries from node_modules/.bin are resolved starting from the directory of each lint-staged configuration file (in monorepo setups). This behavior was broken in lint-staged@16.3.0 where they were only resolved from the current working directory and up.

• #​1845 eb8a4e3 - Do not try to restore untracked files when using --hide-all and there is no initial commit yet.

v17.4.1

Compare Source

Patch Changes

• #​1840 efe5b63 - This is a version-bump-only release because the previous version 17.4.0 was not published to npmjs.com due to problems with GitHub Actions and Changesets.

v17.3.0

Compare Source

Minor Changes

• #​1825 16b3f74 - It is now possible to run multiple tasks in parallel for a single glob by configuring it with an array of tasks (which run sequentially), and then placing another array inside it (where the tasks will run in parallel). The following demonstrates the order tasks will start in:

  {
    "*.ts": ["first", "second", ["third", "third"], "fourth"]
  }

  As a concrete example, lint-staged's own configuration is:

  /** @type {import('./lib/index.js').Configuration} */
  export default {
    '*': [
      ['oxfmt --check --no-error-on-unmatched-pattern', 'oxlint --no-error-on-unmatched-pattern'],
    ],
    '*.ts': () => 'tsc',
  }

  which means:

  1. for all staged files, run the two commands in parallel with staged filenames appended, for example:
     • oxfmt --check --no-error-on-unmatched-pattern lib/index.js
     • oxlint --no-error-on-unmatched-pattern lib/index.js
  2. additionally, if any *.ts files are staged, run tsc without appending any arguments
  3. The two sets of commands also run in parallel

Patch Changes

• #​1829 15f7e53 - During an in-progress merge, files that are unchanged from the branch being merged are now skipped. Technically, files are only included if there are staged changes against both HEAD and MERGE_HEAD.

v17.2.0

Compare Source

Minor Changes

• #​1823 ee156cc - The chunking of tasks based on maximum command line argument length has been re-implemented to be more precise. Now the chunking happens based on the final generated command string, instead of just the list of staged files like previously. This benefits mainly Windows platforms and function commands like:

  /** @type {import('lint-staged').Configuration} */
  export default {
    '*.ts': () => 'tsc', // Run "tsc" when any TS file is changed (for entire project)
  }

  Where the spawned command is literally "tsc" without any extra arguments. Previously, this was still chunked when a lot of files were staged. Now, it probably won't be chunked because the length of the command is just three letters.

  Also, native JavaScript/Node.js function tasks won't be chunked at all, when previously they were run multiple times when chunked:

  /** @type {import('lint-staged').Configuration} */
  export default {
    '*.js': {
      title: 'Log staged JS files to console',
      task: async (files) => {
        console.log('Staged JS files:', files)
      },
    },
  }

v17.1.1

Compare Source

Patch Changes

• #​1820 a626a9f - It's now possible to set --max-arg-length=Infinity to effectively disable chunking of tasks based on the number of staged files. The parsing and validation of the numeric CLI options --max-arg-length and --concurrency has been improved.

v17.1.0

Compare Source

Minor Changes

• #​1816 7568d4f - The console output of lint-staged has been simplified so that there's less interactive spinners and more explicit messages like "Started…" -> "Done!". The primary purpose of this was to remove Listr2, a very large dependency.

  Before:

  Size of node_modules/ after installing: 1561.7 kB with 29 packages.

  Fancy interactive spinners, but output dynamically changes:

  ✔ Backed up original state in git stash (0b191303)
  ✔ Running tasks for staged files...
  ✔ Staging changes from tasks...
  ✔ Cleaning up temporary files...

  After:

  Size of node_modules/ after installing: 974.0 kB with 5 packages (37.6 % smaller, 82.7 % less transitive dependencies).

  Simpler but more explicit output:

  ⋯ Backing up original state…
  ✔ Done backing up original state (35b38ed1)!
  ⋯ Running tasks for staged files…
      *.js — 1 file
        ⋯ oxlint --fix
      *.{json,md} — 1 file
        ⋯ oxfmt --write
  
  ✔ oxfmt --write
  ✔ oxlint --fix
  
  ✔ Done running tasks for staged files!
  ⋯ Staging changes from tasks…
  ✔ Done staging changes from tasks!
  ⋯ Cleaning up temporary files…
  ✔ Done cleaning up temporary files!

Patch Changes

• #​1816 c19079d - Try to restore hidden unstaged changes when using --no-revert.

• #​1818 efb23a2 - Console output colors are enabled/disabled more consistently.

• #​1818 26112a1 - Failed JS function tasks now properly kill other tasks, unless --continue-on-error is used. Previously their failure didn't affect other tasks.

v12.10.1: pnpm 12.10.1

Compare Source

This release fixes pnpm install failures after an overrides change and on a filtered frozen install with catalogPrune. It also fixes several bugs in the experimental nodeLinker.type: loaded, which now keeps its generated files in node_modules.

Patch Changes

• With nodeLinker.type: loaded, pnpm now writes its generated files to node_modules, which projects already ignore in git. The store manifest and loader are node_modules/.pnpm/.store-manifest.json and node_modules/.pnpm/.store-loader.mjs. Bin shims are in node_modules/.bin.

  Earlier versions wrote .pnpm-store.json and .pnpm-store-loader.mjs to the project root, and a .pnpm directory to the root and to each workspace package. Delete them after reinstalling.

• With nodeLinker.type: loaded, packages that ship their own node_modules directory, such as npm with its bundled dependencies, now load from the store. Before, one such package in the install stopped every Node.js process from starting.

• With nodeLinker.type: loaded, scripts can now run a Node.js runtime installed through devEngines.runtime. Before, every script that called node re-ran its own shim until it failed with "Argument list too long".

• With nodeLinker.type: loaded, Node.js processes start faster. In a project with 13,000 stored files, the startup overhead per process dropped from 67 ms to 18 ms.

• pnpm install no longer fails with ERR_PNPM_NO_MATCHING_VERSION after a change to overrides when the lockfile resolves an optional peer dependency to an npm alias of another package #​16654.

• A frozen install with catalogPrune no longer removes catalog entries that pnpm-lock.yaml still records. Before, pnpm install --frozen-lockfile --filter failed with ERR_PNPM_LOCKFILE_CONFIG_MISMATCH when some workspace projects were missing from disk #​16638.

• pnpm install --fix-lockfile no longer removes the deprecated and hasBin fields from lockfile entries #​6600.

• With enableGlobalVirtualStore, an install that updates node_modules now repairs a package in the global virtual store that an interrupted install left without some of its dependency links or package files. Before, such an install kept the incomplete package if the project's node_modules already recorded it #​16642.

• pnpm install now skips the Cargo and Python projects inside a nested directory that has its own pnpm-workspace.yaml or .git directory, such as a git worktree of the same workspace or a separate clone.

• The Request took warning for package metadata now starts timing when pnpm sends the request. Before, it also counted the time the request waited for a free request slot, so large installs printed it for requests the registry answered quickly.

Platinum Sponsors

Gold Sponsors

v12.10.0: pnpm 12.10.0

Compare Source

This release adds an experimental loaded node linker, lets pnpm-lock.yaml record resolution settings, and reads cached registry metadata faster. It also carries several security fixes, including one that stops a dependency version from writing files outside the global virtual store.

Minor Changes

• Added experimental nodeLinker: { type: loaded } installation. Compatible dependencies load directly from the content-addressable store through an automatically registered Node.js loader. nodeLinker.excluded selects packages and their dependency trees to install in the global virtual store.

• lockfile.includeResolutionSettings: true makes pnpm-lock.yaml record autoDedupe, dedupeInjectedDeps, dedupePeerDependents and linkWorkspacePackages. Installs then treat a lockfile that records other values as outdated. A lockfile that records autoDedupe is reused by later installs on any machine, so pnpm run after pnpm install --frozen-lockfile no longer starts another install #​16583.

Patch Changes

Security

• pnpm install now prevents dependency versions with path traversal from writing files outside the global virtual store.

• pnpm now verifies locked config dependencies against their registry before installing them. Config dependencies must come from an npm registry. The lockfile can no longer replace the integrity of a config dependency pinned with version+integrity.

• Lockfile verification now checks the tarballs inside a variations resolution against the registry. A name@version lockfile entry with an empty variations resolution is now rejected.

• pnpm audit signatures now verifies signatures against the integrity recorded in the lockfile. Packages without a recorded integrity cannot pass signature verification.

• pnpm install and pnpm publish now reject archive metadata larger than 64 MiB before reading it into memory. Publishing a pre-built tarball also rejects manifests and README files larger than 64 MiB.

• Two URL or local path dependencies no longer share a virtual store directory when one URL has +, #, :, or ? where the other has /. Such dependencies, including git dependencies pinned with #, now get a hash suffix on their directory name.

• The warning about an ignored project .npmrc registry setting no longer prints the username and password of a URL-scoped key such as //user:password@registry.example.com/${PATH}/:_authToken.

Installing and resolving dependencies

• pnpm install now fails with ERR_PNPM_UNSUPPORTED_PROTOCOL when a dependency uses a specifier with a protocol pnpm does not support, such as Yarn's patch:. On Windows, such a specifier failed with os error 123. On other platforms, pnpm linked it to a directory that does not exist. Reading a package.json that fails now names the file #​16590.

• pnpm install now fails with ERR_PNPM_PACKAGE_MANIFEST_INVALID_ATTRIBUTE when a project declares a dependency whose specifier is not a string, such as "is-positive": 42. Before, the dependency was silently left out of the lockfile. A readPackage hook can still correct the specifier.

• Fixed pnpm install failing with ERR_PNPM_CMD_SHIM_RESOLVE_PATH when an executable's parent directory contains a dangling symlink.

• pnpm install --frozen-lockfile no longer fails with ERR_PNPM_RESOLUTION_SHAPE_MISMATCH when a name@version lockfile entry has a resolution served by a custom fetcher pnpm/tasks#108.

• pnpm install --fix-lockfile repairs a lockfile whose importer references a package that has no snapshot entry, as left by a badly merged lockfile. It failed with ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY since 12.8.0 #​16618.

• When a dependency moves an exact dependency of its own to an older version, a peer dependency that pnpm installed automatically now moves with it. Before, pnpm install and pnpm dedupe kept the newer locked version of the peer, so the lockfile held two copies of it, for example two copies of vue pnpm/tasks#61.

• pnpm dedupe now reads registry metadata for a dependency pinned to an exact version, as pnpm install does. If the registry metadata disagreed with the package's package.json, the lockfile it wrote depended on whether minimumReleaseAge was set #​16615.

Speed and size

• Dependency resolution reads cached registry metadata faster. The metadata cache moved to <cache-dir>/v12/, so the first install after upgrading downloads registry metadata again. A damaged cache entry is downloaded again, or reported as an error when --offline is set. pnpm cache prune also removes the metadata cache that older pnpm versions wrote under <cache-dir>/v11/ #​13512.

• Package metadata requests no longer wait behind queued tarball downloads when maxSockets or a proxy limits the connections to a registry. Large installs resolve faster and print fewer Request took warnings.

• Sped up installs in large workspaces on macOS when the dependency links already exist. pnpm now keeps a link that already points at the right package without trying to create it first. Relinking the direct dependencies of 1,000 workspace projects took 45 ms, down from 116 ms pnpm/tasks#65.

• Commands in a project that pins a different pnpm version start about 13 ms faster on macOS. pnpm now runs the pinned version's binary directly, without the shell script in front of it pnpm/tasks#66.

• The pnpm binary is about 0.9 MB smaller, and the arm64 Linux binary is about 1 MB smaller still.

Running scripts and commands

• pnpm run no longer prints [ELIFECYCLE] Command failed ... after Ctrl+C ends the script. pnpm still exits the way the script's shell did: on Windows with the shell's exit code (cmd reports -1073741510, PowerShell 1), on Unix by re-raising SIGINT #​16579.

• pnpm run "/<regex>/" now accepts JavaScript regular expression syntax such as lookahead and lookbehind. A selector like "/^hello:(?!b).*$/" failed with ERR_PNPM_NO_SCRIPT #​16604.

• pnpm run and pnpm exec now forward --config.* command-line flags to the install started by verifyDepsBeforeRun pnpm/tasks#60.

• On Windows, a process started by pnpm run or pnpm exec can again start a child with CREATE_BREAKAWAY_FROM_JOB. That child keeps running after pnpm exits, even if the command fails #​16628.

• Empty nodeOptions values from command-line flags and environment variables now override lower-priority settings. Scripts retain NODE_OPTIONS from the parent environment or extraEnv when nodeOptions is empty.

• pnpm now reads the failIfNoMatch setting from pnpm-workspace.yaml, so a filter that matches no workspace project exits with code 1 when the setting is true. The new --no-fail-if-no-match flag turns the setting off for one command #​16577.

Configuration, setup, and pnpm versions

• pnpm config get --global and pnpm config list --global now show only the global configuration, also when run inside a project. Settings from the project's pnpm-workspace.yaml and .npmrc were included before. The same applies to --location=global #​16598.

• pnpm now prints config warnings, such as an unset environment variable in .npmrc, when loading the config fails.

• pnpm 11 releases older than 11.28.4 can run pnpm 12 again when the packageManager field pins it. Since 12.9.0 they failed with SyntaxError: Invalid or unexpected token #​16594.

• On Windows, pnpm self-update no longer runs the update a second time when it replaces a pnpm.cmd linked by pnpm 12.8 or older. cmd.exe read on in the replaced pnpm.cmd, printed an error about a command that is not recognized, and ran the new pnpm once more #​16573.

• pnpm setup now puts $PNPM_HOME/bin first on PATH in login shells that inherited it further down, such as the VS Code terminal on macOS. Before, another node took precedence over the one installed by pnpm runtime set node -g. Run pnpm setup again to update the block in your shell config #​16635.

• pnpm setup now names the shell config file even if it is already up to date #​16608.

Updating, auditing, and publishing

• pnpm update --latest now applies the savePrefix setting when it rewrites a dependency whose range has no operator of its own, such as <2.0.0.

• The interactive pnpm audit --fix picker now shows each patched version with the saveExact and savePrefix style that the override is written with #​13209.

• pnpm unpublish <pkg>@<version> now deletes the tarball under the registry's path when the registry is served under one, such as Gitea's npm registry. It used to send the delete to the host root and report success without removing the version #​16568. It also no longer mistakes a sibling path such as /npm-mirror/ for the registry path /npm/ pnpm/tasks#94.

Output and messages

• A warning about a project's devEngines or packageManager pin is now printed to stderr. A command such as pnpm cache path or pnpm list --json keeps only its own output on stdout #​16584.

• pnpm list now reports the correct package paths when nodeLinker is hoisted #​9593.

• Resolution errors now name the failing dependency and its parent packages. Fatal errors appear as structured error records with their error codes when using --reporter=ndjson.

• The error for an invalid git repository in the lockfile now has the code ERR_PNPM_INVALID_GIT_REPOSITORY. Its message now lists every rejected form of the value.

• pnpm runtime --help and pnpm help runtime now name the set subcommand and the runtimes it accepts #​16580.

Platinum Sponsors

Gold Sponsors

v12.9.1: pnpm 12.9.1

Compare Source

This release moves the WebContainer build into a separate @pnpm/wasm package, shrinks the pnpm package back to about 4 MB, and fixes pnpm publish with provenance from GitLab CI.

Patch Changes

• The WebAssembly build for StackBlitz WebContainers now ships as a separate @pnpm/wasm package. The pnpm and @pnpm/exe packages no longer include it, which brings their unpacked size back from about 55 MB to about 4 MB. In a WebContainer, install @pnpm/wasm with npm to get the pnpm command.

• pnpm publish with provenance from GitLab CI is no longer rejected by the npm registry with a 422 error. The provenance statement now includes the GitLab CI variables in invocation.parameters, as npm does #​16551.

• pnpm audit signatures now uses the TLS settings of the redirect target when a registry redirects its signing-keys request, for example to registry.npmjs.org. A cafile scoped to a private registry no longer makes the redirected request fail #​16541.

• Fixed pnpm install --frozen-lockfile rejecting an up-to-date lockfile when an injected workspace package uses a catalog entry in peerDependencies #​16557.

• The [<since>] filter selector works again with Git 2.24 through 2.27 #​16561. With Git older than 2.24, the selector now fails with an error that names the required Git version.

  It also detects changes in projects whose directory names contain non-ASCII characters. Such a change used to be credited to the parent project. changedFilesIgnorePattern and testPattern now match changed files whose names contain non-ASCII characters.

• The pnpm executable is about 10% smaller. On macOS arm64 it went from 45.1 MB to 40.3 MB.

• Sped up trust downgrade checks for packages with long release histories.

• With optimisticRepeatInstall: false, pnpm install now runs the projects' own lifecycle scripts, such as prepare, even when node_modules is already up to date #​16545.

• pnpm self-update now fails for Homebrew-installed pnpm and prints the brew upgrade command for the installed formula, such as brew upgrade pnpm or brew upgrade pnpm@11. It used to install a second copy of pnpm that the Homebrew one kept shadowing #​16547.

Platinum Sponsors

Gold Sponsors

v12.9.0: pnpm 12.9

Compare Source

This release runs pnpm in StackBlitz WebContainers, adds a per-registry networkConcurrency setting, and records every installed project in the store. It also carries a security fix for pnpm login.

Minor Changes

• pnpm now automatically uses WebAssembly in StackBlitz WebContainers, including when installation scripts are disabled. Native installations continue to use the native executable when installation scripts are enabled.

• A registries entry can now set networkConcurrency, the most requests pnpm keeps in flight to that registry's origin. Requests to other registries keep the overall limit. The setting may live in pnpm-workspace.yaml or the global config.yaml.

  registries:
    https://npm.corp.example.com/:
      scopes: ["@acme"]
      networkConcurrency: 4

• pnpm install now records every project it installs in the store's projects directory, as a symlink to the project directory. A --frozen-store install without the global virtual store still records nothing. Only projects that used the global virtual store were recorded before #​6929.

Patch Changes

• pnpm login no longer forwards credentials in its request body to another origin during redirects.

Installing packages

• Fixed pnpm install failing on Android with ERR_PNPM_STORE_DIR_ACQUIRE_OPERATION_LOCK #​16508.

• pnpm install --frozen-lockfile again succeeds when a workspace project recorded in pnpm-lock.yaml has no directory, such as a project left out of a Docker build context. It still fails if the project's directory exists without a package.json #​16453.

• pnpm install --frozen-lockfile no longer requires a pnpm-lock.yaml in a project that has no dependencies. It also succeeds when pnpm-lock.yaml records only the pinned pnpm version, as other commands write it when they run before the first install #​16477.

• Fixed pnpm install --frozen-lockfile rejecting a fresh lockfile when an injected workspace dependency has an optional peer supplied by another workspace project #​16428.

• With nodeLinker: hoisted, a filtered install now keeps the packages of the workspace projects an earlier install put in node_modules. This also covers the install that pnpm --filter <selector> run and pnpm --filter <selector> exec start before the command. Before, these installs removed every package that only the unselected projects needed #​16483.

• pnpm install with nodeLinker: hoisted now refreshes directories supplied by custom fetchers when reinstalling. pnpm also keeps the symlinks inside those directories.

• With enableGlobalVirtualStore on, scripts can run entry points that a CommonJS require hook loads again, such as ts-node index.ts. They failed with ERR_UNKNOWN_FILE_EXTENSION on Node.js versions without built-in TypeScript support #​16436.

• pnpm now keeps each project's current lockfile and hidden hoisted dependencies in its own node_modules/.pnpm when virtualStoreDir points at a shared global virtual store. --virtual-store-dir now sets the global virtual store's location too pnpm/tasks#47.

• pnpm clean no longer deletes the project when virtualStoreDir or globalVirtualStoreDir is set to the project directory. It also leaves a directory outside the project alone when the setting reaches it through a symlink. It now removes a global virtual store that globalVirtualStoreDir places inside the project, as it does for virtualStoreDir.

Optional dependencies

• pnpm install no longer fails when a dependency of an optional dependency is missing from the registry. Like npm, pnpm now leaves out the nearest optional dependency above it, together with its subtree #​16511.

• When an optional dependency fails to build, pnpm now removes its link from node_modules. A repeat pnpm install then reports "Already up to date" and no longer reruns the failing build #​16468.

• pnpm install now prints a warning with the error when an optional dependency cannot be fetched and is skipped. The skipped package is no longer counted in the Packages: +N summary. The pnpm:skipped-optional-dependency log reports the skip with the fetch_failure reason #​16514.

Resolving dependencies

• Fixed pnpm install changing an unchanged project's direct dependency to a sibling workspace's pinned version when its dependency tree contains a cycle #​16417.

• With autoDedupe enabled, downgrading a dependency in one workspace project now moves the other projects to that version when it satisfies their ranges. This also applies to a filtered pnpm --filter <project> add #​16432.

• pnpm install and pnpm dedupe now move an optional peer to the version already in the dependency graph when no other package provides its locked version anymore. After a bump such as vue 3.5.40 to 3.5.43, the lockfile kept a second copy of @vue/server-renderer for @vue/test-utils #​16443.

• pnpm dedupe --check no longer fails right after pnpm install when a project's optional peer is satisfie

❗ Important

✂ PR body was truncated to here.